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(54) Kommunikationssystem mit Mitteln zum Austausch von Software 



(57) Die Erfindung bezieht stch auf ein Kommunika- 
tionssystem mil einer Steuerschaltung (3. 9). welcheein 
zum Austausch von Nachrichten vorgesehenes Be- 
triebssystem (4) und Anwendersoftware (5) und Mittel 
(11) zum Austausch von Software enihalt: Dam it eine 
Sottwarekomponente innerhab weniger Millisekunden 



ausgetauscht werden karm, empfangt eine neu gelade- 
ne Sottwarekornponente (Nachfolgerkomponente) Zu- 
stande und Nachrichten von etnem Dtenst-Port einer 
angehaltenen, zu ersetzenden Softwarekomponente 
(Vorgangerkomponente) . Die Nachfolgerkomponente 
wird mit den ubertragenen Zustanden und Nachrichten 
neu gestartet 
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Beschreibung 

BESCHREIBUNG 

s Kommunikationssystem mil Mitletn zum Austausch von Software 

Die Erfindung bezteht sich aul ein Kommunikationssystem mit einer Steuerschattung, wetche eln Betriebssystem 
unci Anwendersoftware und Mittel 2um Austausch von Software enthaft. 

Kornrnunikationssysterne enthatten Compulersysteme Oder Steuerschaltungen, deren Software langlebig und 
praktisch dauernd vertugbar sein soil. Bei Fehlern in der Sollware Oder aucb aufgrund neuer Anforderungen mOssen 
10 bestlmmte Soflwarekomponenten erneuert werden. Dabei soilte die Ausf allzeit des Kommunikationssysterns minimiert 
werden. 

Ein Kommunikationssystem, welches paktisch keine Ausf allzeit bei dem Austausch einer Software einer Kompo- 
nente eines Vermittlungssystem aufweist, ist aus der US-A-5 155 837 bekannt Vor dem Austausch werden zuerst cfie 
Inhalte und Zustande alter Register Prozesse und Speichereinheften in einem speziellen Speicher wahrend des Be- 

15 triebes der alten Software gesichert (SpaDe 7, Zeilen 30 bis 36). Die arte Version der Software ist dabei in einer ersten 
Partition geladen. Die neue Software wird anschfieBend in eine zweite Partition geladen. Nachdem die neue Software 
geladen und getestet worden ist, werden aus dem Speicher die Inhalte und Zustande alter Register. Prozesse und 
Speichereinheiten aul die neue Software Obertragen. Diese wrrddann v\ Betrieb genommen. Die neue Software beginnl 
dabei jedoch nicht an dem ProzeBpunkt zu aibeiten, an dem die alte Software angehalten worden ist, sondem an 

20 einem def inierten Programmpunkt. Es werden auch nicht einzefrie Softwaremodule oder -komponenten, sondem eine 
in sich geschtossene Software ausgetauscht. 

Der Erfindung liegt daher die Auf gabe zugrunde, Softwarekomponenten auszutauschen, bei wetcher auBer einer 
kurzen Verzogerung keine Einschrankung des Betriebes erfolgt. 

Die Auf gabe wird durch ein Kommunikationssystem der eingangs genannten Art dadurch getost, 

2B daB das Betriebssystem zum Austausch von Nachrichten vorgesehen ist und daB eine neue geladene Softwarekom- 
ponente (Nachfolgerkomponente) zum Empfang der Zustande und d8r Nachrichten von einem Dienst-Port einer an- 
gehaltenen, zu ersetzenden Softwarekomponente (Vorgangerkomponente) und zum Neustart mit den ubertragenen 
Zustanden und Nachrichten vorgesehen ist. 

Die Erfindung ermoglicht den Neustart der neuen Softwarekomponente an dem Programmpunkt, an dem die alte 

30 Softwarekomponente angehalten worden ist . AuBerdem werden alle Zustande der alien Softwarekomponente zur neu- 
en Softwarekomponente Obertragen. Dies kann aber nur fur solohe Systeme getten, die ein Betriebssystem aufweisen, 
welches den Austausch von Nachrichten zwischen Softwarekomponenten ermoglicht. Hierbei werden Nachrichten 
uber Softwareschnittstellen, die im tofgenden als Ports bezeichnet werden, zwischen verschiedenen Prozessen aus- 
getauscht. Erf indungsgemaB werden also in der atten Softwarekomponente alle Zustande und alte an einem Dienst- 

35 Port anliegenden Nachrichten eingesammeit und zur neuen Softwarekomponente Obertragen. Uber etnen Dienst-Port 
emptangt die Softwarekomponente alle Nachrichten von anderen Prozessen. Die neue Softwarekomponente uber- 
nimrnt die neuen Zustande, fuhrt gegebenenfalts eine Zustandstransformation durch und starlet die neue Software in 
dem Programmpunkt der neuen Softwarekomponente, der dem der alten Softwarekomponente entsprtcht 

Der Austausch einer Softwarekomponente erfolgt dabei so. daB keine andere Softwarekomponente davon beruhrt 

40 wird. Die von einer anderen Softwarekomponente etntrefienden Nachrichten werden narnlich auf die neue Software- 
komponente Obertragen und nach dem Austausch weiterverarbeitet. Der Autausch erfolgt dabei so, daB nur eine kurze 
Verzogerung bei der Bearbertung entsteht. Praktische Untersuchungen haben ergeben, daB die Verzogerungszeit im 
Bereich wentger Msttisekunden liegl 

Ein Kommunikationssystem kann ein Computersystem sein, eine Vermitttungsstelle, ein Computemetzwerk oder 

45 auch Server systeme, wie z. B. ein Vide-On-Demand-Server. E in Computerssy st em enthaft wenigstens einen Computer, 
in dem eine Softwarekomponente ausgetauscht werden son. 

Eine Softwarekomponente Oder ein ProzeB enthaft genau einen Thread. Ein Thread ist ein in sich setost sequentiell 
ablaut endes Programmstuck. Dei Thread weist etnen ersten Teil zur Ubernahme und geeigneten Umsetzung der Zu- 
stande und Nachrichten des Dienst-Ports einer alten Softwarekomponente und einen zweiten TeB zum Einsammetn 

50 der Zustande des Prozesses und der Nachrichten des Dienst-Ports auf. 

Der Austausch einer Softwarekomponente wird von einem Austauschmanager gesteuert, wetcher zum Laden und 
Starten einer Softwarekomponente vorgesehen ist Die neue Softwarekomponente kann dabei von einer Wartungs- 
vornchtunganden Austauschmanager gelrefert worden sein, an der auch neue Softwarekomponenten entwickelt wer- 
den kormen. Als Obertragungsmedium kann betspielswoise das Telefonnetz cftenen. 

55 AusfOhrungsbetspiete der Erfindung werden nachstehend anhand der Figuren naher ertautert. Es zetgen: 

Fig. 1 em Computersystem mit einer Wartungsvorrichtung und einem Computer, der austauschbare Softwarekom- 
ponenten enthaft. 
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Fig. 2 den NachrichtenfluB zwischen dem Austauschmanager. einer neuen und alien Softwarekomponente, 
Fig. 3 ein Vermittlungssystem mil einer Wartungsvorrichtung und einer Steuerschaltung, die austauschbare Soft- 

warekomponenten enthalt. 
Fig. 4 ein Zustandscfiagramm einer nicht austauschbaren Softwarekomponente und 
Fig. 5 ein Zustandsdiagramm einer austauschbaren Softwarekomponente. 

In Fig. 1 ist ein Computersystem mit einem Computer 1 und einer Wartungsvorricntung 2 dargestellt. Der Computer 
enthalt Haro\varekomponenten 3, ein Betriebssystem 4, Anwendersoftware 5 und einen Austauschmanager 11. Das 
BetriebssVstem 4 mu8 eine Kommunikation zwischen Softwarekomponenten der Anwendersoftware 5 Ober Nachrich- 
ten ermogjichen (z.B. nachrichtenorientiertes Betriebssystem (message based operating system)). Die Nachrichten 
Oder Daten werden dabei uber Softwareschnrttstellen ausgetauscht. Im fotgenden wird eine Softwareschnittstellen als 
Port bezeichnet. 

Der Austauschmanager 11 ist eine Softwareprogramm, mit dessen Hilfe Komponenten der Anwendersoftware 5 
ausgetauscht werden konnen. In der Fig. 1 sind die einzetnen Softwarekomponenten durch Kreise dargestellt Die 
Verbindungen zwischen den Kreisen sollen Nachrichtenflusse zwischen den Softwarekomponenten andeuten. 

Die VVartung^vorrichtungvorTichtung 2 konnte ein entleml liegender Computer sein, von dem a us eine neue Sott- 
warekomponente gelietert wird. Hierbei ist es denkbar, da8 die neue Softwarekomponente an diesem Computer ent- 
wickelt und geiestet wird. Zur Obertragung der neuen Sottwarekomponente konnen bekannte Obertragungsmedien 
und Protokoile verwendel werden. Beispielsweise ist eine Obertragung uber ein Teletonnetz mogiich. Die neue Soft- 
warekomponente konnte aber auch direkt in den Computer 1 getaden werden (z.B. mit Hille einer lokalen Wartungs- 
vorrichtung (Laptop)). 

Der Austauschmanager 11 lad! die neue Softwarekomponente in den Computer 1 und start et sie dort Die neue 
Komponente meldet sich bei dem Austauschmanager 11 an und bekommt mitgeteilt, ob sie eine existierende arte 
Komponente ersetzen soli. Falls das der Fall ist, sendet die neue Komponente, die eine Nachfolgerkomponente dar- 
stellt, einen Austauschbef ehl (request) an die alte Komponente, die eine Vorgangerkomponente darstellt. Die Vorgan- 
gerkomponente sammelt ihre Zustandsinlormationen und ubertragt diesen Zustand zur Nachfolger komponente. Au- 
Berdem meldet die vorgangerkomponente dem Austauschmanager 11, da8 sie gestoppt hat. Danach setzt die Nach- 
folgerkomponente die Arbeit exakt an der Stelte fort, an der die vorgangerkomponente gestoppt wurde. Damit dieser 
Austausch, ohne daB der Computer auBer Betrieb genommen wird, duichgefuhrt werden kann, sind in den Kompo- 
nenten der Anwendersoftware noch bestimmte Veranderungen gegenuber nicht austauschbaren Komponenten vor- 
genommen worden. 

Wie oben erwahnt mussen die Softwarekomponenten. welche austausch bar sein sollen, gegenuber konventb- 
nellen Softwarekomponenten Erwerterungen besitzen. Erne Softwarekomponente weist genau einen Thread auf. der 
einen Dienst-Port fur den Enapfang von Nachrichten (messages) von einem Klienten und einen Teil zur Antwort auf 
die Nachrichten an einen Klienten autweisl. Ein Thread ist ein in sich selbst sequentiel! ablaufendes Programmstuck. 
Ein Klient ist eine andere Softwarekomponente (ProzeB). Darnrt eine Softwarekomponente austauschbar wird. muB 
sie einen Austausch-Punkt bzw. Restart-Punk! im Thread aufweisen. In der Regel sind der Austausch-Punkt und der 
Restart-Punkt identisch. 

In Fig. 2 ist schematisch der NachrichtenfluB zwischen dem Austauschmanager 11 (hier als AM bezeichnet), der 
Vorgangerkomponente VK und der Nachfolgerkomponente NK dargestellt Nachdem die neue Komponente NKvcm 
Austauschmanager gestartet worden ist (Pfeil ST), werden von dieser bestimmte Intoonationen geholt (Punkt P1 ). Die 
Vorgangerkomponente VK ermogticht am Punkt P2 die Erfullung ihrer Aufgaben, d.h. z.B. die Bearbeitung exlemer, 
anliegender Nachrichten. Die Nachfc^rkornponente NK meldet sich dann beim Austauschmanager 11 (AM) an (Pfeil 
AN), der anschlieOend der Nachfolgerkomponente NK den Befehl zum Austausch der Komponenten gibt (Pfeil EX1). 
Dieser Befehl wird von der Nachfolgerkomponente NK weiter an die Vorgangerkomponente VK gegeben (Pfeil EX2). 
Darauthin sammefl die vorgangerkomponente VK ihren Zustand (Punkt P3) und liefert diesen an die Nachfolgerkom- 
ponente NK (Pfeil ZU). Die Nachfolgerkomponente NK rekonstruiert aus den empfangenen Zustanden die ObjeWe 
und fuhrt gegebenfaDs erne Zuslandslransformation durch. Alte Nachrichten die wahrend des Austauschvorgangs fur 
einen Dienst-Port der Vorgangerkomponente VK bestimmt war en, werden da durch zum Dienst-Port der Nachfolger- 
komponente NK gegeben. Ansch lie Bend meldet die Vorgangerkomponente VK dem Austauschmanager 11 (AM) : daB 
sie gestoppt hat (Pfeil VG) und Idscht sich (Punkt P4). Die neue Komponente NK ubemtmmt danach die Bearbeitung 
der exteme Nachrichten (Punkt P5). 

Der Computer 1 konnte beispielsweise auch ein Server in einem Computernetzwerk sein. Eine weitere Anwerv 
dungsmoglichkeit besteht fur Systeme, welche zur Obertragung von Nachrichten vorgesehen sind. Ein Beispief ist ein 
Vermrttlungssystem. deren wesentliche Biocke in Rg. 3 gezeigt sind. Das Vermirtlungssystem enthalt ein Koppelfeld 
6 wefches auf Eingangsleitungen 7 empfangene Signale an eine oder mehrere Ausgangslertungen 8 weitergfct. Zur 
Steuerung des KoppetfeWes dient eine Steuerschaltung 9, die auBer den notwenrjgen Hardwarebestandteiten ein 
Betriebssystem. Anwendersoftware und einen Austauschmanager enthalt. Zum Austausch von Komponenten der An- 
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wender software ist eine Wartungsvorrichtung 10 vorgesehen, die mil der Steuerschaltung 9 auf dieselbe Weise wie 
die Wartungsvorrichtung 2 m& dem Computer 1 zusammenarbeitel 

Anhand ernes in der Programmiersprache C++ geschriebenen Proz esses soff rm folgenden etwas detaillierter der 
Aulbau einer austauschbaren Software komponente erfautert werden. Zuerst wird der konventionelle Autbau des Pro- 
zesses ohne die fur den Austausch notwendigen, erfindungsgernaBen MaBnahmen beschrieben. Der ProzeB ermog- 
licht mittels Spracheingaben ein Telefonbuch zu verwaften. Der Teletonbuch-ProzeB steIR anderen Prozessen drei 
Methoden zur Verf ugung. Das ist erslens das Hinzufugen eines Eintrages zum Teletonbuch, zweitens das Loschen 
eines Eintrages aus dem Telefonbuch und drittens das Ermitteln ernes Eintrages aus vorgegebenen Sprachdaten. Ein 
ProzeQ lietert dazu dem Telefonbuch-ProzeB eine Nachricht, aus der cfie entsprechende gewunschte Methode her- 
ausgefunden wird. Die Implementation des Telefonbucn-Prozesses ist im tolgenden aufgetOhrt: 



(1) #include *audiodat.hxx" // Klasse 'AudioData' zur Sprach-Reprasentation 



^include "bin.hxx" 



// Nachrichten-Puffer-Klasse 'Bin 1 



^include "port.hxx" 
^include "s.hxx" 



// String-Klasse S* 

// Thread-KIasse 'Thread 5 



// Port-Klasse Tort* 



^include " thread. hxx* 



(3) class PhoneBook { 

// ... Hier befinden sich die Definitionen der 



// 



internen Datenstmkturen des Telefonbuchs. 



public: 



void enter(S name, unsigned phoneNumber, AudioData reference) { 



// ... Einfugen eines Names mil Telefonnummer 



// und Sprachreferenz in das Telefonbuch 
void remove(S name) { 



// ... Loschen eines durch den Namen 



// referenzierten Eintrages aus dem Telefonbuch 



} 
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void give(AudioData reference, S& name, unsigned* phoneNumber) { 
// ... Finden eines Eintrages im Tetefonbuch 
// basierend auf einer Sprachreferenz 

} 

}; 

(8) enum Request { Enter, Remove, Give }; 

(9) Port* phoneBookEntry; // Nachrichtenadresse fur meine Klienten 
PhoneBook* phoneBook; // Reprasentiert das Telefonbuch 

(10) void phoneBookServiceO { 

(13) phoneBookEntry = new Port( "phoneBookEntry", Port:: Overtype); 
phoneBook = new PhoneBook; 

(14) while(l) { 

( 15) Bin message; phoneBookEntry- > receive(message); 
int request; 

message > > request; 

// Extrahiert Typ der aufgerufenen Methode aus 
// empfangenen Daten. ■ 

(16) switch(requesi) { 

case Enter: { 

S name; unsigned phoneNumber; AudioData reference; 
message > > name > > phoneNumber > > reference; 
phoneBook- >enter(name, phoneNumber, reference); 

} 

break; 

case Remove: { 
S name; 

message > > name; 
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phoneBook- > remove(name); 

} 

break; 
case Give: { 

AudioData reference; S name; unsigned phoneNumber; 
message > > reference; 

phoneBook- > give( reference, name. phoneNumber); 
message.c!ear(); 

// Loschen, weil er fur die Ruckantwort gebraucht wird 
message < < name < < phoneNumber; 

// Zusammenstellung Ruckantwort 
reply (message); 

} 

break; 

} 

} 

} 

(18) Thread pBS(phoneBookService) ; 

// Deklariert und startet den Thread des sprachgesteuerten Telefonbuchs. 

Bei der oben dargestellten Implementation sind nur die Deklarationen aufgetuhrt, wetehe zum verstandnis des 
Teletonbuch-Prozesses erforderlich sind. Das Programm enthaft zur Bezugnahme Abschnittsnummem, welche nicht 
Bestandleil des Pfogrammtextes sind Einzelne Programmabschnrtte werden jeweils durch vorangestelfte, in Klam- 
mem angegebene Zahlen gekennzeichnet. 

In den Abscnitten (1 ) und (3) sind Importe und Deklarationen von Klassen von Objekten enthaiten, die im Tetefon- 
buch-ProzeB verwendet werdenjn dem Abschnitt (1 ) werden einige Bibtiotheken (Headerdateien) in den ProzeB ein- 
gebunden, die verschiedene weitere Kbssen zur Vertugung sleDen. Diejeweaio^BedeutmgdereBizelnenBibliotheken 
ist in den Kommentarzeflen ertautert. 

AbschnitI (3) zeigl die Definition etner internen Tetetonbuch-Klasse "PhoneBook". Die Implementationen fur 
"Enter", 'Remove" und "Give" sind nicht im einzelnen aufgeluhrt. Die Methode 'Enter* erlaubl das Entugen eines 
Namens mil Tetefonnummer und Sprachreferenz (Sprachprobe) in das Tetefonbuch, die Methode "Remove" erlaubt 
das Loschen eines durch den Namen ret erenzierten Eintrages aus dem Telef onbuch und die Methode "Give' ermoglicht 
das Finden eines Eintrages im Tetefonbuch der auf ew\er Sprachreterenz basiert In diesem Fall sucrrt jemand atso 
Ehtrage unter einen Namen, den er spracNich vorgibt. Die Methoden 'Enter", 'Remove' und "Give" erhaften und 
ubergeben Jeweils die in den KJammem zu den jewetligen Methoden angegebene n Parameter. 

In Abschnitt (8) sind die Methoden aufgefuhrt, d&e der Tetefonbuch- ProzeB anderen Prozessen zur Vertugung 
stem. In Abschnitt (9) ist der Port (Dienst-Port) defmiert, uber den die Methodenaufrule von anderen Prozessen an das 
Tetefonbuch ertolgen. Ein Port dient zur Versendung von Nachrichten an andere Prozesse. In AbschnitI (9) wird auch 
das Telef onbuch-Objekt "PhoneBook' deklariert. das ebenso wie die vorherige Port-Deklaraiion den Zusland des Soft- 
wareobjektes bildet. Das Objekt •PhoneBook' verwattet afle relevanten Daten des Tetefonbuchs. 
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In den Abschnitt (10) bis (16) wird die Hauptlunktion des Tefefonbuch-Prozesses angegeben. Diese Funktion wird 
als Thread ausgefuhrt Der Thread besleht aus einen Inlialsierungstefl im Abschnitt (13) und etner Endlosschleile (ab 
Abschnitt (14)), in der Methodenaulruf e emptangen werden (Abschnitt (1 5)) und in der die Methodenauf ruf e ausgefuhrt 
werden (Abschnitt (16)). Im Initiafisterungsteil im Abschnitt ( 1 3) wird der Ant an gszu stand des Softwareobjekles gesetzt 
In der Schleite, die mit Abschnitt ( 1 4) beginnt. wird auf eine Antorde rung gewartet. Falls eine Nachricht von dem Dienst- 
Port empfangen worden ist (Abschnitt (15)) wird diese im Puffer "message" abgetegl. Die Nachricht enthaB immer 
zuerst den Typ der autgerufenen Methode und je nach Methode noch zusatzliche Parameter. In Abhangigkea vom Typ 
(Request) wird entweder zur Methode "Enter", zur Methode "Remove" Oder zur Methode "Give" gesprungen. Die Me- 
thode "Enter" f Dgt in das Telefonbuch-Objekt "phoneBook" den Namen, die Telefonnummer und eine Sprachreferenz 
ein. Die Methode "Remove" entfemt aus dem Tetefonbuch-Objekl "phoneBook" den Namen mit den enlsprechenden 
Eintragungen. Fur die Methode "Give" wird z.B. noch eine Sprachreferenz ubermittelt, die in eine variable "reference" 
vom Typ "AudioData" abgelegt wird. Uber einen Autrul der Methode "Give" des intemen Objekts "phoneBook" werden 
dazu ein Nutzemame "name" und erne Telelonnummer "phoneNumber' ermrttelt und mittels des Befehls "reply" an 
den Klienten gesendet, der nach der enlsprechenden Telefonnummer gelragt hat. In Abschnitt (16) ist eine Deklaration 
aufgefDhrt, durch die der Thread instantiiert, mit der die Funktion "jphoneBookService" verbunden und gestartet wird. 
Die Funktion "phoneBookServtce" beginnt ab Abschnitt (10). 

Der A Waul des Threads kann durch das h der Fig 4 dargestePte Zustandsdiagramm noch welter veranschaulicht 
werden. Block 23 bezeichnet den Zustand (Zustand L, loaded), in den das gesamte Sottwareobjekt von dem Aus- 
tauschmanager 11 in den Arbefisspetcher des Computers 1 Oder der Steuerschaltung 9 geladen wurde. Nach der 
Initialisierung tritt der Thread in einen Iniliafisterungszustand (Zustand I, initialized), was der Block 24 angibt. Der 
nachste Zustand RAC (running application code) zeig! die eigentliche Ausf uhrung des Threads (Block 25) und wird im 
Programm durch die Abschnitte (14) bis (16) beschrieben. Der Zustand RAC weist weitere Unterzustande WFR (Block 
26, warting for requests), ME (Block 27, processing "enter"), MR (Block 28, processing "remove") und MG (Btock 29. 
processing "give") auf. Der Pfeil mit dem Punkt aut der linken Seite des Blockes 26 kennzeichnet den Unterzustand, 
der eingenommen wird, wenn das Programm in den Obergeordneten Zustand eintritt. Im konkreten Beispiel hetQt das. 
daB der Zustand RAC Bnmer mit dem Unterzustand WFR beginnt. Im Zustand WFR wird auf Nachrichten gewartet. 
Nach Eintretlen einer Nachricht wird in einen der Zustande ME, MR oder MG gesprungen. Diese Zustande korrespon- 
dieren mit der Ausf uhrung der Methoden "Enter", "Remove" und "Give" Nach Beenden einer der Methoden wird in 
den Zustand WFR zuruckgesprungen 

Um den Austausch einer Soflwarekomponente durchzufuhren, ist der oben ctergesteHle Teletonbuch-ProzeB durch 
weitere Deklarationen zu erweitem. Diese zusatzlichen Abschnitte und die schon oben beschriebenen Abschnitte des 
Telefonbuch-Prozesses sind im tolgenden aufgefDhrt: 
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(1) ^include "audiodai.hxx* 
^include "bin.hxx" 
#include "port.hxx" 
^include "s.hxx" 
#include "thread.hxx" 

(2) ^include "exchange-nxx" 



// Klasse 'AudioData' zur Sprach-Reprasentation 

// Nachrichten-Puffer-Klasse 'Bin' 

// Port-Klasse Tort' 

// String-Klasse 'S' 

// Thread-KIasse 'Thread' 

// Deftniert 'getExclnfo' und 'setExcInfo' 



15 



35 



(3) class PhoneBook { 

// ... Die hier deklarierten internen Daienstrukturen 
// des Telefonbuchs sollen verandert werden. 
public: 

void emer(S name, unsigned phoneNumber, AudioData reference) { 
// ... Einfugen eines Names mit Telefonnummer 
// und Sprachreferenz in das Telefonbuch 

} 

void remove(S name) { 

// ... Loschen eines durch den Namen 

// referenzierten Eintrages aus dem Telefonbuch 

} 

void give( AudioData reference, S& name, unsigned& phoneNumber) { 



40 



55 
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// ... Die (hier nicht aufgefuhrte) Implementation 
// dieser Methode ist verbessert worden. 

} 

PhoneBookO {}; // Standardkonstruktor 

(4) PhoneBook(Bm buO { 

// Zusaizlich hotwendiger Konstruktor zur 

// Erzeugung des Objektes aus einem Putferabbild. 

} 

(5) static Bin& operator < <(Bin& buf) { 

// ... Zusatzlich notwendige Methode zum 
// Ablegen des Objektzustandes in einen Puffer, 
return buf; 

} 



35 



40 



(6) class CHdPhoneBook { 
public: 

OldPhoneBook(Bin buO { 

//■... Zur Erzeugung eines alten Objektes aus dem empfangenen 
// Zustand. 



// ... Die restliche Schnittstelle ist mit der 

// im zu ersetzenden Sofiwareobjekt idemisch. 



}; 



(7) PhoneBook stateTransformation(OldPhoneBook phoneBook) { 
PhoneBook newPhoneBook; 
so ff ... Diese Funktion erledigt die norwendigen Transformationen 

// vom alten 'phoneBook 1 zum neuen 'newPhoneBook*. 
return newPhoneBook; 



55 
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} 

(8) emim Request { Enter, Remove, Give, Exchange }; 

(9) Port* phoneBookEntry; // Nachrichienadresse fur meine Klienten 
PhoneBook* phoneBook: // Reprasentiert das Telefonbuch 

(10) void phoneBookServiceO { 

Bin state; 

(11) if (geiExclnfo( "phoneBookEntry", Bin() << (int)Exchange, 10000, 
state)) { 

(12) phoneBookEntry = new Port(state): 
OldPhoneBook oidPhoneBook(state); 

phoneBook = new PhoneBook(stateTransformation(o!dPhoneBook)); 
}else{ 

(13) phoneBookEntry = new PortCphoneBookEntry", Port:: Overtype); 
phoneBook = new PhoneBook; 

} 

(14) while(l){ 

( 1 5) Bin message; phoneBookEntry- > receive(niessage); 
int request; 

message > > request; 

// Extrahiert Typ der aufgerufenen Methode aus 
// empfangenen Daten. 

(16) switch(request) { 

case Enter: 

// ... keine Anderungen 
case Remove: 

// ... keine Anderungen 
case Give: 
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// ... keine Anderungen 

(17) case Exchange: { 

Bin state; 

state < < phoneBookEntry- > migTateO < < phoneBook; 

// Zustand sammeln 
delete phoneBookEntry; delete phoneBook; 

// Aufraumen noch existierender Objekte 
setExclnfo(state); // Keine Ruckkehr aus dieser Funktion. 

} 

} 

} 

} 

(18) Thread pBS(phoneBookService); 

// Deklariert und starlet den Thread des sprachgesteuerten Telefonbuchs. 



Der oben gezeigte Programmablauf ist fur den Fall vorgesehen. daB diese Softwarekomponente eine andere 
(Vorgangerkomponente) ersetzen soil, und fur den anderen Fall, daB diese Softwarekomponente durch eine andere 
neue Softwarekomponente (Nachfolgerkomponente) ersetzt wird. Die Softwarekomponente, welche die erfindungs- 
gemaBen MaBnahmen enthalt, verwendet ein zusalzliches Modul 'exchange.hxx" (Abschnitt (2)), das zwei Methoden 
"getExclnfo" und "setExclnfo" zur verfugung stellt Die Methode "getExclnfo" stellt die Zustandsinforrnationen der zu 
ersetzenden Komponente der neuen Komponente zur Verfugung. Demgegenuber Obergibt die Methode "setExclnfo" 
Zustandsinforrnationen der aktuellen Komponente an eine sie ersetzende neue Komponente. Jeder Thread rutt also 
zu Begrnn seiner Abarbeitung genau einmal die Methode "getExclnfo" und beendet seine Abart>eitung mrt "setExdnfo" 
(vgl. die unten aufgefuhrten Prc^rammablaufe). 

Die DekJaratbnen cm Abschnitt (3) werden urn zusatzBche Methodenaufruf e erweitert, cfie in den auf den Abschnitt 
(3) folgenden Abschnitten (4) und (5) aufgefuhrt sind Prinzpieil werden alle intemen Objekte. soweit noch nicht vor- 
handen, urn zwei weitere Methoden erweitert. Eine Methode ist erforderfich. urn den neuen Zustand des Objektes der 
Nachfolgerkomponente aus dem Zustand eines ahnlichen Objektes der \Aorgangerkomponente zu konstruieren (Ab- 
schnitt (4)} und eine weitere Methode. urn den Zustand der Vorgangerkomponente in eine als Nachnchl versendbare 
Form zu verpacken (Abschnitt (5)). Es wird der Melhodenauf rut 'PhoneBook (Bin but)- verwendet, der ein Objekt aus 
einem PutferabbiW konstruiert (Abschnfll (4)). Dieser Methodenaufrut wird benotigt, wenn tie beschriebene Software- 
komponente den Zustand in res intemen Objekles •phoneBook" aus dem ubertragenen Zustand vom "phoneBook" der 
Vorgangerkomponente gewinnl. ZusatzBch wird in Abschnitt (5) eine Methode aufgerufen. die das Ablegen des Ob- 
jektzustandes in ekien Puffer erlaubt Diese Methode ist erforderlich, wenn die hier beschriebene Softwarekomponente 
(Vwgangerkc)mponente)den Zustand ihres intemen Objektes ■phoneBook" an eine Nachfolgerkomponente ubertragen 
mochte. 

PrmzipieU ist es zulassig, daB die intemen Objekte einer Nachfofgerkomponente nicht identisch mit den intemen 
Objekten der zu ersetzenden Komponente (Vw gangerkomponente) sind In dem Ausf uhrungsbeispiel soil das fur das 
interne Objekt "phoneBook" der Fall sein. Gefost wird diese Inkompatfoilitat durch die BerertsteHung einer Transfer- 
funktion 'stateTransformation" (Abschnitt (7)). Diese Funktion muB in der Lage setrv den alien Typ "OldPhoneBook" 
(Abschnitt (6)) des intemen Objektes "phoneBook" in seine neue Representation umzuwandeta Das erfoJgt unmittel- 
bar. nachdem der Zustand der alten Objekte empfangen wurde (siehe Abschnitt (12)). 

Der Abschnitt (8) gfct ernen vom Objekt berertgesteliten weiteren Dienst an. Dieser Dienst "exchange" ermoglichl 
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den Austausch der Softwarekomponente. 

Der Thread des Tel efonbuchproz esses enthaft zwei zusatztiche Programmleile. Einer ist fur die Ubemahrne der 
Zustande von einer Vorgangerkomponente und der andere Teile fur (fie Ubergabe der Zustande an eine Nachf oJger- 
komponente verantwortlich. Ob eine Vorgangerkomponente existiert wird mfflete der Methode "getExclnfo* (siehe un- 

s ten) ermittett. Existiert eine sotehe, dann ubermittelt "getExclnfo" auch den Zustand der vorgangerkomponente. Dieser 
wird zur Rekonstruktion der internen Objekte "phoneBookEntry* und "phoneBook" benutzt (Abschnitt (12)). Existiert 
keine Vorgangerkomponente, dann wird die Komponente ganz norma! gestartet (Abschnitt (13)). Das Erzeugen des 
neuen Dienst-Ports wird mit den Anweisungen in den Abschnftten (12) und (1 3) realisiert. Alle noch nicht abgearbeiteten 
Nachrichten des Dienst-Ports der alten Softwarekomponente sind Bestandtefl von diesem Zustand und werden uber- 

io geben. Wetter wird im Abschnitt (12) der alle Zustand des Telefonbuches aus dem Puffer 'state" extrahiert und in der 
Variablen "oldPhoneBook" abgelegt. Die oben beschriebene Zustarxlstransferfunkt'ion, die den Zustand eines alten 
Telefonbuches in den Zustand eines neuen Telefonbuches abbiktet, wird in Abschnitt (12) angewendet. Ein solcber 
Transfer ist beispielsweise erfordernch, wenn ein neues FeW "Postletaahten" hinzukommt oder d&eses Feld einen 
anderen Typ erhaft (z.B. 5 anstatt 4 Zetchen). 

'5 Der zweite neue Programmteil (Abschnitt (1 7)) realisiert den fur den Austausch der Komponente gegen eine Nach- 

folgerkomponente notwentfigen Dienst "Exchange" Zuerst wird in Abschnrtt (17) der augenblickliche Zustand der alten 
Softwarekomponente (Vorgangerkomponente) in einem Puffer "state" abgelegt. Es werden z.B. der Zustand ein- 
schlieBlich der Nachrichten des Dienst-Ports "phoneBookEmry" in dem Puffer "state" gespeicherl Der in dem Puffer 
"state" abgetegle Zustand der alten Softwarekomponente wird mittete "setExclnfo" an die neu einzusetzende Sott- 

& warekomponente (Nachfolgerkomponente) gesendet. Die Methode "setExclnfo" bricht gleichzeitig die Softwarekom- 
ponente ab. 

Der Ablaut des Threads in der Softwarekomponente mit den erfindungsgemaBen MaBnahmen kann ebenfalls 
durch ein Zustandsdiagramm beschrieben werden. welches in der Fig. 5 gezeigt ist. Alle Zustande, die mit denen in 
der Fig. 4 identisch sind, weisen dieselben Bezeichnungen auf. Der Zustand RS (Block 30, receiving state) gibt den 

2S Zustand nach einem Neustart der Softwarekomponente an, bei der auf die Ubertragung des Zustandes der alten Kom- 
ponente gewartet wird. Erhalt die Softwarekomponente am Ende forer Lebensdauer dann selbst ein Austauschsignal, 
wechselt sie in den Zustand CS (Block 31 , collecting state), in diesem Zustand sammelt sie die Zustande rhrer internen 
Objekte. Der Zustand TS (Block 32 : transferring state) gibt die Ubertragung der Zustande von der alten auf die neue 
Softwarekomponente an. Das Beenden einer atten Softwarekomponente wird durch den Zustand TE (Block 33, ter- 

30 minated) angegeben. 

Das Modul "exchange.hxx", welches die Methoden "getExclnfo" und "setExclnfo" definiert. wird im folgenden auf- 
gelistet: 

iKfndef FLYER_EXCHANGE 
^define FLYEREXCHANGE 

include "bin.hxx" 

im getExcInfo(const char 3 * portName, const Bin& excReqCode, int maxState. 
Bin& state); 

void setExclnfo(const Bin& state); 
#endif 

In Abschnitt (1) wird ein Symbol "FLYER_EXCHANGE" getestet und, faDs es nicht definiert ist, gesetzt. Das ver- 
55 hinder! das mehrtache Inkludferen (Eintugen) dieses Modufe. Abschnitt (2) inktudiert die Definition der K lasso "bin". 
Die Methode "getExclnfo", welche die Zustandinforrnationen fur die Nachfolgerkomponente Kefert, wird in Abschnitt 
(3) definiert. Die Methode besitzt die Parameter "port Name", "excReqCode", "maxState", •state" und "return". "port- 
Name" gibt den Namen des Ports an. uber den die Leistungen dieser Somvarekompooente in Anspruch genommen 



35 



(1) 



4S 



(2) 
(3) 



(4) 



EP 0 743 595 A2 



werden. 'excReqCode" ist ein Antorderungskode, der zur Einleitung des Austauschvorganges an die arte, zu erset- 
zende Soflwarekomponente gesendet werden soil. Die maximale GroGe des erwarteten Zustandes in Byte gibt "max- 
Stale" an. In "state* wird der zu Obertragende Zustand des Threads abgelegt. Der Ruckkehrwert der Funktion "getEx- 
clnfo" ist gleich 0 (FALSE), falls kein Ausiausch stattfinden soD, dh. falls die Komponenle einlach nur neu gestarlet 
werden sdl. 

In Abschnitt (4) wird cfie Methode definiert, wefche die Zustandsinformationen des alien Threads der Vbrganger- 
komponente, die in "state" abgelegt sind, an die Nachfolgerkomponente uberbringt. Die Funktion "setExclnfo* kehrt 
nicht zuruck. Der au! ruf ende Thread wird geloscht. 

Das Modul "exchange.cxx*, dessen Prog ram ma Waul unten dargestelt ist, beinhaltet die Implementierung der in 
dem Modul "exchange.hxx' beschriebenen Schnittstelle: 



(1) include "exchange.hxx" // Eigene Schnittstellenbeschreibung 

^include "excsiub^hxx" // Schnittstelle zum Austausch-Manager 'ExcStub' 

include "port.hxx' // Definiert Tort' 

include "thread.hxx" // Definiert 'mySelf 

(2) const int False = 0, True = !0; 



(3) 
(4) 



static ExcStub excStub; 
static S servicePonName; 



// Schnittstelle zum Austausch-Manager 
// nur fur internen Namenstransfer 
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(5) int getExcInfo(const char* portName, const Bin& excReqCode, int maxState. 
Bin& state) { 

servicePortName = ponName; - // merken fur 'setExdnfo' 

(6) // Anmeidung beim Austausch-Manager: 
ExcStub::ReplyCode re = excStub.announce(servicePortName); 
if (rc == ExcStub::OkStart) return False: 

// kein Ersetzen sondern Neustan 



(7) // Austauschaufforderung an die zu ersetzende Komponente schicken: 
Port servicePorUportName, Port:: Reference); 
servicePort.calKexcReqCode, maxState, state); 

// Die Anforderung wird verschickt und der alte Zustand empfangen. 

return True; 

} 

(8) void setExcInfo(const Bin& state) { 

reply(state); 

excStub.stopped(servicePortName); 

// Fertigmeldung an den Austauschmanager 

mySeif()->deletesO; 

} 

Abschnitt (1) enthaft Import e bzw. Dektarattonen verwendeter Klassen. SostetH z.B. "excstub_ hxx" eine Schnitl- 
stelle zum Austauschmanager ll.zur Vertugung. Abschnitt (2) definiert die Konstanten 'False* und "True". 

Abschnitt (3) dektariert etn Objekt "excStub". fiber das der Austauschmanager 11 angesprochen wird. Abschnitt 
(4) dektariert em String-Objekt, das lediglich zum Informatfonsuanster (Namenstransler) zwischen "getExclnto" und 
"setExclnto" benutzt wird. 

Im Abschnitt (5) beginnt die Implementation der Methode "getExctnfo". Im Abschnitt (6) meldet sich die Software- 
komponente beim Austauschmanager 11 an und erfahrt, ob sie neu gestartet wird oder ob sie eine existierende Kom- 
ponente (Vorgangerkomponenle) ersetzen soil. 

Soli erne Vorgano^rkomponente ersetzt werden, so wird im Abschnitt (7) etn Relerenz-Port geschaffen, der den 
Dienst-Porl der zu ersetzen den Komponente referenziert. Der Vorgangerkomponente wird nun ein Austauschbefehl 
nutlets "servicePoit.caH" gesendet Sie schtckl darauthin rhren Zustand zuruck, der in 'state' abgespeichert und ats 
Parameter "stale' von 'getExclnto' Oborgeben wird. 

Abschnitt (8) enthafl die Imptementterung von "setExclnto". Dabei wird zuerst der eingesammelte Zustand "state" 
an den Sender des Austauschbelehte zuruckgeschickt ("repfy(state)") Dann wild der Austauschmanager 11 inform iert, 
daB die Scftwarekomponenle (Vorgangerkomponente) gestoppt hat ("excStub.stopped(servicePortName)") und die 
Softwarekomponente loscht sich selbsl. 



EP0 743 595 A2 



Patentansprucho 

1. Kommunikationssystem mit einer Steuerschaltung (3. 9), wetehe ein Betriebssystem (4) und Anwendersoftware 
(5) und Mittei (11) zum Austausch von Software enthait, 

dadurch gekennzeichnet, 

daB das Betriebssystem (4) zum Austausch von Nachrichten vorgesehen ist und daB elne neue geladene Soft- 
warekomponente (Nachfolgerkomponente) zum Empfang der Zustande und der Nachrichten von einem Dienst- 
Port einer angehaBenen, zu ersetzenden Sctftwarekomponente (vbrgangerkomponente) und zum Neustart mit 
den ubertragenen Zustanden und Nachrichten vorgesehen isl 

2. Kommunikationssystem nach Anspruch 1 . 
dadurch gekennzetchnet, 

daB eine austauschbare Softwarekomponente einen Thread enthait und daB der Thread einen ersten Teil zur 
Clbemahme und geeigneten Umsetzung der Zustande und Nachrichten des Dienst-Ports einer alien Software- 
komponente und einen zweiten Teil zum Einsammetn der Zustande des Prozesses und der Nachrichten des Dienst- 
Ports enthait. 

3. Kommunikationssystem nach Anspruch 1 Oder 2, 
dadurch oekennzelchnet 

daB ein Austauschmanager (11) zum Laden und Starten einer Softwarekomponente vorgesehen ist. 

4. Kommunikationssystem nach Anspruch 1 , 2 oder 3, 
dadurch gekennzeichnet, 

daB eine Wartungsvorrichtung (2, 10) zur Lieferung einer neuen Softwarekomponente fiber em Obertragungsme- 
dium an den Austauschmanager (11 ) vorgesehen ist. 

5. Kommunikationssystem nach einem der vorhergehenden AnsprOche, 
dadurch gekennzeichnet, 

daB bei einer veranderten Struklur der Nachfolgerkomponente zur Vbrgangerkomponente die Nachfolgerkompo- 
nente zur Durchfuhrung einer Zustandstranformation vorgesehen ist. 

6. Computersystem mit wenigstens einem Computer (1 ). weteher ein Betriebssystem (4) und Anwendersoftware (5) 
und Mittei (11) zum Austausch von Software enthait, 

dadurch gekennzeichnet; 

daB das Betriebssystem zum Austausch von Nachrichten vorgesehen ist und daB eine neue geladene Software- 
komponente (Nachfolgerkomponente) zum Empfang der Zustande und der Nachrichten von einem Dienst-Port 
einer angehaBenen, zu ersetzenden Softwarekomponente (vbrgangerkomponente) und zum Neustart mil den 
ubertragenen Zustanden und Nachrichten vorgesehen ist. 



FIG. 1 




FIG. 3 
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